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includes a connection handler system. The connection 
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the mobile communication device and to select a 
corresponding connection handler. The connection 
handler is operable to select one or more transcoders 
from the plurality of transcoders to transcode the 
information content. 
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SYSTEM AND METHOD FOR PROVIDING REMOTE DATA 
ACCESS FOR A MOBILE COMMUNICATION DEVICE 
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Source To A Mobile Communication Device" and filed December 19, 2001. The 
complete disclosures of all of the above-identified provisional applications are hereby 
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20 Pushing Data From An Information Source To A Mobile Communication Device" and 

filed on 1 2002, the complete disclosures of which are hereby incorporated 

into this application by reference. 
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Field of the Invention 

This invention relates generally to mobile communications, and in 
particular to providing access to remote data from mobile communication devices. 

5 Description of the State of the Art 

Known solutions for providing remote access to data using mobile 
communication devices tend to be relatively limited. For example, Wireless Application 
Protocol (WAP) browsers for mobile devices typically provide access only to information 
associated with WAP-compliant sources. Although other known and similar products 

10 may allow a mobile device user to access further information sources, such products 
generally do not make efficient use of mobile communication network resources, 
particularly wireless communication links, and often require processor-intensive 
operations such as information parsing to be executed on the device. 

Furthermore, most known data access systems and methods are not 

15 suited to provide truly secure access to confidential information stored on private 
networks, such as corporate information located on a data store behind a security 
firewall. 

SUMMARY 

20 The instant application describes a system and method for providing 

mobile communication devices with access to remote information sources. 

The systems and methods described herein provide for access to any of a 
plurality of types and formats of information. Information translation operations may be 
performed on an information source side of a mobile communication system in order to 
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reduce the complexity of device processing operations and any device hardware and 
software components associated with such operations. 

In one exemplary embodiment,, a system for providing data access 
between an information source and a mobile communication device includes a 

5 transcoding system and a first network device. The transcoding system includes a 
plurality of transcoders, and. each transcoder is operable to transcode information 
content from a respective first content type into a respective second content type. The 
first network device is in communication with the transcoding system and includes a 
connection handler system. The connection handler system is operable to receive 

10 connection data for a connection between the information source and the mobile 
communication device and to select a corresponding connection handler. The 
connection handler is operable to select one or more transcoders from the plurality of 
transcoders to transcode the information content. 



15 BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a general block diagram of a communication system that provides 
access to a remote information source from a mobile communication device. 

Fig. 2 is a more detailed block diagram of the system shown in Fig. 1 . 
Fig. 3 is a flow chart representing general connection handler-related 
20 operations in the system. 

Fig. 4 is a flow chart of connection handler data processing operations. 
Fig. 5 is a signal flow diagram showing the extension of accepted content 
types by an HTTP connection handler based on available transcoders. 

Fig. 6 is a signal flow diagram showing multiple transcoding operations for 
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an HTTP operation. 

Fig. 7 is a general block diagram of a communication system with an 
external transcoder system. 

Fig. 8 is a signal flow diagram illustrating an example HTTP operation for 
5 an external transcoder system such as shown in Fig. 7. 

Fig. 9 shows a further signal flow diagram for an external transcoder 

system. 

Fig. 10 is a block diagram of a communication system with an external 
transcoder system and an external connection handler system. 
1 o Fig. 1 1 is an example signal flow diagram for the system of Fig. 1 0. 

Fig. 12 is a signal flow diagram illustrating delegation of an information 
request to an external connection handler. 

Fig. 13 is a signal flow diagram showing a variation of the request 
delegation of Fig. 12. 

15 Fig. 14 is a signal flow diagram showing hand-off of a request to an 

external connection handler. 

Fig. 1 5 is a block diagram showing an IP Proxy system implemented in a 
secure network. 

Fig. 16 is a signal flow diagram illustrating a corporate data access 

20 operation. 



DETAILED DESCRIPTION 

General System Description 

Fig. 1 is a general block diagram of a communication system 10 that 
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provides access to a remote information source 20 from a wireless mobile 
communication device ("mobile device") 12. In Fig. 1 , the system 1 0 includes a mobile 
device 12, a wireless network 14, a gateway 15, a wide area network (WAN) 16, an 
Internet Protocol (IP) Proxy system 18, and an information source 20. Although an IP 
5 Proxy system 1 8 is shown in the illustrative example system of Fig. 1 , proxy systems for 
protocols other than IP may be implemented in accordance with the systems and 
methods described herein. Protocols at other levels within the Open Systems 
Interconnection (OSI) model can also be proxied using these systems and methods. 
Such other protocols include, but are not limited to, Hypertext Transfer Protocol (HTTP) 

10 and Transmission Control Protocol (TCP). 

The mobile device 1 2 may be any mobile device adapted to operate within 
a wireless communication network 14, and is preferably a two-way communication 
device. The mobile device 12 may have voice and data communication capabilities. 
Depending on the functionality provided by the mobile device 1 2, the mobile device 1 2 

15 may be referred to as a data messaging device, a two-way pager, a cellular telephone 
with data messaging capabilities, a wireless Internet appliance or a data communication 
device (with or without telephony capabilities). As will be apparent to those skilled in the 
field of communications, the particular design of a communication subsystem within the 
mobile device 12 will be dependent upon the communication network 14 in which the 

20 mobile device 12 is intended to operate. For example, a mobile device 12 destined for a 
North American market may include a communication subsystem designed to operate 
within the Mobitex™ mobile communication system or DataTAC™ mobile 
communication system, whereas a mobile device 12 intended for use in Europe may 
incorporate a General Packet Radio Service (GPRS) communication subsystem. Those 
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skilled in the art will also appreciate that other types of mobile devices and networks are ' 
also contemplated. The systems and methods described herein may be implemented in 
conjunction with virtually any wireless network 1 4. 

The gateway 15 shown in Fig. 1 provides an interface between the 
5 wireless network 14 and a WAN 16, which may for example be the Internet. Such 
functions as device addressing, conversion of data between WAN protocols and 
wireless network protocols, storing and forwarding data to and from the mobile device 
12, and other interface functions may be performed by the gateway 15. 

It is also possible that an IP Proxy could be hosted by a network 
10 carrier/operator associated with the wireless network 14. In this case the connection 
between the IP Proxy 1 8 and the gateway 1 5 would use a private network of the carrier 
instead of the WAN 1 6. The WAN would then be used to communicate between the IP 
Proxy 18 and the information source 20. 

The IP Proxy 1 8 is a system that effectively provides the mobile device 1 2 
15 with access to the information source 20 and is described in further detail below. 
Through the IP Proxy 1 8, the mobile device 1 2 may access any information source 20, 
such as an Internet or web server, that can communicate with the IP Proxy 18. The 
information source 20 therefore requires no special applications or protocol support for 
wireless network communications, since it communicates with the IP Proxy 18 and not 
20 directly with the mobile device 1 2. Although shown in Fig. 1 as a direct connection, the. 
IP Proxy 1 8 and information source 20 may also communicate through a network such 
as a local area network (LAN) or WAN, including the Internet. 

Wireless networks and the Internet use similar addressing schemes, in 
which recipients, such as mobile devices in a wireless network or Internet-connected 
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computers, are identified by numerical addresses. For example, mobile devices are 
identified in the Mobitex network using Mobitex Access Number (MAN) and public 
Internet nodes are identified using an IP address scheme. However, differences 
between wireless network and Internet transport mechanisms prevent direct 
5 communication between information sources 20, the vast majority of which are Internet- 
based, and mobile devices 12. Furthermore, information source content is largely 
targeted to desktop or other computer systems with relatively powerful processors and 
may require that processor-intensive operations such as information parsing be 
. performed by a recipient. Since mobile devices tend to have less powerful processors, 

10 these operations take more time on such devices than on computer systems and can 
consume significant amounts of power from normally limited-power sources. The IP 
Proxy system 1 8 bridges the gap between Internet-based and possibly other information 
sources 20 and a wireless network 1 4 with associated mobile devices 1 2. The services 
supported by the IP Proxy 18 may include address mapping, content transformation and 

15 verification, and protocol mapping and optimisation, for example. 

Detailed Description of the IP Proxy 

Fig. 2 is a more detailed block diagram of the IP Proxy 1 8 shown in Fig. 1 . 
The IP Proxy 18 may include a dispatcher 22, a.TCP handler 24, an HTTP handler 26, 
20 a transcoding system 28, one or more push services generally designated 30, a state 
persistence element 34, a monitoring system 36, and a logging system 38. Fig. 2 also 
shows a push server 42, a web server 46, a web browser 48, and a file system 40, with 
which the IP Proxy 1 8 may interact from time to time. Many of the components shown in 
Fig. 2 may be implemented primarily as computer software modules. Elements within 
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the IP Proxy 18 will typically be running on the same computer, whereas components 
external to the IP Proxy 18 are normally resident on separate computers. In an 
alternative embodiment, the elements of an IP Proxy may instead be distributed among 
a group of computers distributed over a network. 
5 Dispatcher 22 manages data flows and the connection to the gateway 1 5. 

Depending on the type of connection or the type of data being transferred or data 
transaction being performed, for example, the dispatcher 22 interacts with the TCP . 
handler 24 or the HTTP handler 26. The transcoding system 28 comprises one or more 
data filters, each of which converts data or other information from one format into a 

1 o format that can be processed by a mobile device 1 2. 

Push services 30 provide for transfer of "unsolicited" information from an 
information source such as push server 42, which may, for example, be a web server or 
a software application, to a mobile device 12 through the IP Proxy 18. The push 
services component 30 allows the push server 42 to address the mobile device 12 

15 using, for example, the email address of the mobile device owner or some other 
convenient label. Accordingly, the push server 42 need not know the address of the 
mobile device 12 in the wireless network 14. 

The state persistence element 34, in conjunction with a data file system 
40 or a database, enables management of cookies, passwords and possibly other state 

20 information associated with web servers 46 to which the IP Proxy 18 may connect. It 
preferably stores state information about a connection that persists between discrete 
network packets, such as an HTTP request/response pair. The monitoring system 36 
allows remote monitoring of the performance, efficiency, usage and health of an IP 
Proxy 18 by an administrator through an interface such as a web browser 48. As its 
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name implies, the logging system 38 may be configured to store usage, connection, 
user statistics and the like to the file system 40 or some other secondary storage. 

Connections and Handlers 
5 The IP Proxy 1 8 can preferably handle and process content from various 

information sources 20, including Internet-based sources. This functionality is provided 
by connection handlers, which are intermediate objects that have the ability to process 
content from inbound and outbound connections to an IP Proxy system 18. In the IP 
Proxy 1 8 shown in Fig. 2, two such handlers, the TCP handler 24 and the HTTP handler 

10 26, are shown. These handlers can preferably be replaced and customized or additional 
handlers can preferably be added to an IP Proxy 18 as needed. The connection 
handlers can optimise not just the content but also the protocol. For example, some 
requests that would normally be sent to the mobile device 12 (such as a request for a 
password) may be resolved by the connection handler, where requested data has been 

15 stored in the file system 40 or another store accessible to the connection handler, 
through the state persistence element 34, for example. This instance of a protocol 
optimisation can adapt so-called "chatty" protocols to be more wireless friendly by 
reducing the amount of traffic sent over a wireless network to a mobile device, thereby 
reducing the effects of wireless network bandwidth constraints and latency. 

20 Outbound connections are made from mobile devices 1 2 in order to send 

data to and receive data from other entities such as Internet nodes. The IP Proxy 18 
preferably receives connection requests from mobile devices 12 using a particular 
protocol, such as a proprietary protocol called IP Proxy Protocol or IPPP developed by 
the assignee of the present application. Other protocols may also be used. The IP 
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Proxy 18 then establishes an Internet connection, according to protocol and routing 
information provided by the mobile device 1 2 in the connection request, and translates 
and maps that connection to start forwarding data in both directions. A data filtering or 
transcoding process is invoked whenever necessary, based on the type of content 
5 being passed over the connection, for example. Such outbound connections will be 
described in further detail below, in the context of web browsing operations. 

Inbound connections can be used, for example, to implement a data push 
model. In this model, a mobile device 12 may be sent information without having issued 
requests to fetch the information, as is the case with outbound connections. As 

10 described briefly above, mobile devices 12 may exist on a different network domain 
than Internet nodes. The IP Proxy 18 is responsible for bridging the Internet and 
wireless network domains. Thus, the IP Proxy 1 8 requires certain routing information to 
route the traffic to a particular mobile device 12. In a push operation, at least some of 
this routing information must be provided by the Internet node, such as the push server 

15 42, that issues the request to establish an inbound connection. The IP Proxy 1 8 may 
convert commonly known addressing schemes such as email or IP numbers into the 
appropriate wireless network address of an intended recipient mobile device 1 2. . 

Connection handlers in an IP Proxy system 1 8 are stream-based objects. 
When an outbound or inbound connection is requested, a virtual piped stream is 

20 established between mobile device 12 and the appropriate connection handler. The 
connection handler will be instantiated and started to process the content for the 
established connection. Loading of the connection handler is based on a connection 
request, which preferably contains a reference to appropriate handler name that implies 
the type of the traffic that would normally go through the virtual piped stream and the 
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location of the handler that must be loaded if is not already loaded. The functions of 
connection handlers include mapping Internet or other information source-side 
connections and mobile device-side connections, forwarding traffic between these 
connections, and loading and invoking the appropriate transcoders on information 
5 destined for a mobile device. 

Every connection is preferably associated with an instance of a connection 
handler. This is true even for a connection that does not require that content be 
processed by the IP Proxy 1 8, such as a pure TCP connection between a mobile device 
and a server. This type of connection handler forwards content back and forward 

10 without making any sort of modification to the content, although it may make 
modifications to the protocol. For clarity, those skilled in the art will appreciate the 
distinction between the data or content (what the mobile device requested or is being 
sent) and the protocol (the "wrappers" and conversions required to deliver the data). 

Connection handlers are also responsible for loading the appropriate 

15 content filters or transcoders. In the above example, if the web server 46 returns 
Hypertext Markup Language (HTML) content for example, the HTTP connection handler 
26 would then use an HTML transcoder in the transcoder system 28 if the mobile device 
cannot accept HTML content. 

Fig. 3 is a flow chart representing general connection handler-related 

20 operations in an IP Proxy system 18. At step 50, the IP Proxy system 18 receives a 
connection request, which as described above may relate to an inbound connection or 
an outbound connection. When the connection is associated with a particular handler, 
such as an HTTP connection that requires HTTP connection handler 26, the 
appropriate handler is loaded and executed at step 54 and the connection is 
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established, as indicated at step 58. If the request is outbound (from the mobile device 
12), then the dispatcher 22 examines the protocol type associated with the connection 
request and delegates the connection to the appropriate handler. Data may then be 
exchanged between a mobile device 12 and an Internet service, push server 42, web 
5 server 46 or other information source 20. 

If certain connection handlers, such as for a pure TCP connection as 
described above, are used for a connection, then the data may pass through the IP 
Proxy system 1 8 unchanged. In some IP Proxy systems however, content sent over a 
TCP handler may be modified. When other connection handlers are used however, 
10 data destined for a mobile device 12 may need to be converted into a suitable, final 
content. 

Fig. 4 is a flow chart of connection handler data processing operations. At 
step 62, data destined for a mobile device 12 is received. Although labelled as a 
response from a connection, following an information request from a mobile device 1 2, 

15 for example, it will be understood that data received by the connection handler may 
instead be information to be pushed to the mobile device 12 from a push server such as 
42 via push service 30. Based on the type of data received at step 62, the connection 
handler determines at step 64 if transcoding is required. If not, then the information is 
sent to the mobile device 12 at step 70, Otherwise, the appropriate transcoder is loaded 

20 and executed in step 66. The data is transcoded into an acceptable format in step 68 
before being sent to the mobile device 1 2, as described in more detail below. The entity 
that initiates the communication, the mobile device 12 for fetched data or the push 
server for pushed data, can preferably instead request a specific transcoder to do the 
transcoding of the fetched or pushed data. 
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A connection handler may be implemented in computer software as a 
Java™ class file, placed in a certain directory in a file system such that an IP Proxy 
Java Virtual Machine (VM) may locate and load the file when needed or requested. As 
those skilled in the art will appreciate, Java uses CLASSPATH environment variable as 

5 a guide to where it should perform a lookup for user defined classes. In one 
embodiment, paths to connection handlers are to be among the first listed paths in the 
CLASSPATH so that they would be loaded relatively quickly when requested. The 
connection direction (inbound or outbound) and the name associated with a connection 
handler may also play a role in defining the full class name of a handler. Those skilled 

10 in the art will appreciate that the same scheme could be implemented using dynamic 
linked libraries (DLLs) or dynamic shared objects (DSOs) depending on the target 
operating system. 

Connection handlers can be associated with a name that represents a 
protocol at the application layer. For example, if a mobile device 12 is enabled with a 

1 5 web browser and may therefore request to open connection to an Internet server such 
as 46, it would be appropriate to have HTTP as a name for that connection handier, as 
shown with connection handler 26. The handler name may adhere to the known rules 
of naming packages in Java language. The handler name is in lower case; however, 
from an IP Proxy point of view, it does not matter as long as the Java VM can load that 

20 connection handler. Any Connection Handler may also have its class name as 
Handler.class. An example of a valid full class name that represents a connection 
handler is as follows: 

netJim.protocoUplayer.conne^ handler 
25 name>.Handler.class ' 
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where connection direction can be either device, which implies outbound connection, or 
server, which implies inbound connection. Connection handler name is the name 
associated with the handler, for instance, http, ftp, etc. 
5 There are at least two ways that an information source such as an Internet 

node can establish a connection to a mobile device 12 through the example IP Proxy 
system 18 shown in Fig. 2: (1) using a transportation layer protocol directly, such as 
TCP, to open a direct connection to the IP Proxy 18, or (2) using a datagram protocol at 
the application layer, such as HTTP. The IP Proxy system 18 includes two 

10 corresponding connection handlers, which may for example represent a basic IP Proxy 
system 1 8 which can process two of the most common types of connection. The first is 
the TCP connection handler 24, associated with the name tcp, for example. The second 
is the HTTP connection handler 26, which may similarly be associated with the name 
http, as described above. In addition to supporting common connection types, these 

15 connection handlers also satisfy requirements for Mobile Information Device Profile 
(MIDP) implementation at the mobile device 12. However, the IP Proxy 18 and the 
mobile device 12 can be extended to support any other types of connections. In the IP 
Proxy 18, connection handlers may possibly be added by providing an application 
programming interface (API) in the IP Proxy system 18 and developing new connection 

20 handlers that adhere to the API for example. 

In one embodiment, connection handlers in the IP Proxy 18 are loaded 
from a local storage medium, for example a disk drive associated with a computer on 
which IP Proxy software is running. In another embodiment, connection handler 
storage may also or instead be remote from the IP Proxy system 18, such as in a 
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storage medium accessible by the IP Proxy 18 through a local area network (LAN) 
connection or even. a WAN like the Internet. This embodiment allows sharing of a 
single directory of connection handlers among all IP Proxy systems 18 that can 
communicate with the connection handler store. It is also be possible to have third 
5 parties extend the connection handler set by embedding the U RL where the connection 
handler java class can be found. 

If connected to the Internet, a connection handler directory could 
potentially be accessed and thus shared by all Internet-connected IP Proxy systems 1 8. 
Public Internet-connected connection handler directories would preferably receive 

10 connection handler requests from IP Proxy systems and in response transmit any 
requested connection handlers to the requesting IP Proxy system 18. A new 
connection handler may be required by an IP Proxy system 1 8 when a mobile device 1 2 
which communicates with the IP Proxy system 18 downloads a new application or 
invokes a new mobile device feature which uses a new connection scheme or a 

15 connection method that was not previously used by the mobile device 12. A mobile 
device user or the new application or feature may then send a control message to the 
IP Proxy system 18, indicating for example the name of the required connection 
handler, perhaps the mobile device application that requires the new connection 
handler and an address associated with a connection handler directory from which the 

20 new connection handler may be requested. The IP Proxy 18 would then preferably 
request the new connection handler from the directory. A connection handler directory 
could be implemented for example as a web server accessible to an IP Proxy system 1 8 
using HTTP requests. 

When a connection handler is loaded from a remote source, the IP Proxy 
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1 8 preferably stores the handler in a local store in order to provide for faster loading of 
the handler for subsequent operations involving the corresponding type of connection 
for either the mobile device 12 for which the connection handler was initially loaded 
from the directory or a different mobile device 1 2 supported by the IP Proxy system 1 8. 
Depending upon the memory resources available to an IP Proxy system 18, 
downloaded connection handlers may be stored indefinitely or for a particular period of 
time. Alternatively, a least recently used or LRU replacement scheme could be used to 
provide for more efficient use of available memory by overwriting relatively less 
frequently used connection handlers when new handlers are downloaded. Other 
memory management techniques could also be used to optimize local IP Proxy 
connection handler storage arrangements. 

Transcoding 

« 

Relative to computer networks such as the Internet, wireless 
communication networks are slow. Any system that bridges the two, as the IP Proxy 
does, may have to transform Internet data so that it is formatted appropriately for a 
wireless network and mobile device. This process is referred to herein as filtering or 
transcoding, and usually involves such operations as compressing data from the 
Internet into a more compact format appropriate for wireless transmission. 

In the following description, transcoding operations are illustrated primarily 
in the context of the above example of an HTTP handler 26 and HTTP connection. The 
HTTP connection and handler example is particularly useful in that HTTP allows 
content tags in the form of Multipurpose Internet Mail Extension (MIME) types, which 
may be used to determine the appropriate transcoder for received information. 
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In accordance with the IP Proxy system 18 disclosed herein, there is a 
single configuration file for each type of connection handler. In the IP Proxy 18 for 
example, a single configuration file is associated with the HTTP connection handler 26 
and includes information for all HTTP content transcoders. This configuration file is 
5 used to map transcoders to certain content types. The IP Proxy 18 may consult this file - 
to determine which content transcoder it should load to manipulate any received content 
destined for a mobile device. 

In the configuration file, general rules are preferably specified for how to 
define the mapping between content types and transcoders. One example of a possible 
1 ci configuration file entry is as follows: 

Entry = {[default] : { RSV | <Transcoder name>}} | 

{ [[ InputType] | < ->OutputType> ] : [ Transcoder name] } 

where 

15 default indicates to the IP Proxy which default transcoder should be 

loaded in case there is no one transcoder associated with a received content type; 

RSV is a set of reserved keywords that is used in configuration file, such 
• as pass (i.e. forward data to the mobile device without transcoding) or discard (i.e. do 
not transcode or forward data to the mobile device); 
20 Transcoder name is the name of the mapped transcoder; 

InputType indicates the input content type that the mapped transcoder 
accepts, which for an HTTP transcoder configuration file may be a MIME type; and 

OutputType indicates the output type, such as a MIME type for an HTTP 
transcoder, that the transcoder generates. 
25 By using a content transcoder configuration file new transcoders may be 
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added for use by the IP Proxy 18. Therefore, as new transcoders are developed and 
become available, they can be added to the configuration file for any appropriate 
connection handlers and can thereafter be loaded by a connection handler when 
required, and without affecting other components of the IP Proxy system 18. For 
5 example, configuration file entries may be added without shutting down the entire IP 
Proxy system 18, thus allowing dynamic expansion of data that can be converted for 
transmission to mobile devices 12. 

In another embodiment, a common configuration file format for all 
connection handlers is used, and thus a only single configuration file entry need be 

10 prepared and can be added to the configuration file for any connection handler. The 
concept of a common configuration file format for all connection handlers can be further 
extended to providing a single configuration file for an IP Proxy 18. Such a 
configuration file could be used by all connection handlers in the IP Proxy 18 to 
determine which content transcoders are available and to select a particular transcoder 

15 for received content. However, it should be understood that a common configuration file 
format is in no way required. Some connection handlers may share a configuration file 
entry format or even a single configuration file, whereas others supported by the same 
IP Proxy 18 may have different configuration files and entry formats. 

The IP Proxy 18 preferably loads a transcoder based on the available 

20 information regarding the content type of the data being either pushed to or pulled from 
mobile device 12. The IP Proxy 18 may use accept and content type header fields to 
decide which transcoder should be loaded. Several illustrative example content 
transcoder loading control schemes are described in further detail below. Although 
these examples relate primarily to HTTP connections and handlers, those skilled in the 
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art will appreciate that other connection types and handlers may use similar 
arrangements and methods to select a transcoder when content is received at an IP 
Proxy system 18. 

It should also be appreciated that a transcoder may instead be selected 

5 based upon information other than content types, including information in a header 
portion or other portion of a connection request from a mobile device, a response to a 
connection request, or a communication from an information source including 
information to be pushed to a mobile device. For example, an IP Proxy system 1 8 may 
be configured to determine a type of the mobile device 12 to which data is to be sent. 

1 o Transcoder selection by the IP Proxy system 1 8 could similarly be based on a network 
address or other identifier of the mobile device 12. Mobile device- or device type- 
dependent transcoder selection schemes may be supported by providing a device or 
device type mapping table accessible to the IP Proxy system 1 8, which maps devices or 
device types to transcoders. Alternatively, a configuration file may be adapted to 

1 5 include device or device type identifiers to thereby associate particular transcoders with 
devices or device types. 

In a similar manner, transcoders may be selected based on an address 
(such as a URL) or other identifier of an information source, to enable information 
source-specific transcoding. A mapping table or a configuration file accessible to an IP 

20 Proxy system such as 1 8, may be used to enable transcoder selection based on 
information source. This type of transcoder selection may be useful, for example, when 
a particular transcoder is to be used to transcode any content that originates from a 
specific website and is destined for a mobile device. 

Although content type-based transcoder selection is the primary type of 
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transcoder selection scheme described below, any of these alternative schemes may 
be used instead of content type-based transcoder selection. The alternative schemes 
may also be used to select a transcoder, for example, when a transcoder indicated by a 
primary transcoder selection scheme is not available, such as when a transcoder 

5 system does not include a transcoder configured to transcode a received content type 
into a content type that the mobile device is configured to accept. 

An HTTP connection handler in an IP Proxy system 18 will normally 
attempt to load a transcoder based on Accept line and the Content-Type header fields. 
The IP Proxy may load a transcoder if it has information regarding the content type(s) 

10 that a mobile device 12 is configured to accept and the content type that a server or 
other information source 20 returns. For example, in this case the HTTP connection 
handler 26 in the IP Proxy 18 may use an lnputType->OutputType key format to consult 
its configuration file when configuration file entries include content type fields, as in the 
above example file entry. 

15 The HTTP connection handler 26 may also load a transcoder if it has 

information only about the server or source 20 content type but not what the mobile 
device 12 can accept. In this case the, the IP Proxy 18 can use the InputType key 
format to consult its configuration file. If the connection handler is unable to determine 
which transcoder should be used, it will preferably load a predetermined default 

20 transcoder. When the default transcoder is used, the IP Proxy 18 may send an error 
message to a mobile device 1 2 if the output content type of the default transcoder is not 
acceptable by the mobile device 12 or if the default is discard (see the above example 
configuration file entry). Since most data pull-based information sources such as web 
servers do not embody automatic resend or retry functions when such delivery errors 
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occur, error messages will normally be sent only to the requesting mobile device 1 2. A 
mobile device user may then send a new request to retrieve the information. However, 
when the information originates at a push server 42, an error may be returned to the 
sending server, which may then initiate a new push operation. 
5 Consider the case of a simple HTTP operation in which no Accept header 

is specified. A mobile device user or an application on the mobile device 12 issues an 
HTTP request indicating no Accept header field of content types that the mobile device 
12 or application can accept. The IP Proxy 18 may, in the absence of Accept header 
information, infer that any type of content can be accepted and forward the request to 

10 the appropriate information source 20. When information content destined for the 
mobile device 12 in response to the request is received by the HTTP connection 
handler in the IP Proxy 18, the content is sent to mobile device 12 as is, regardless of 
content type. Since the mobile device 12 in this case can presumably accept any 
content type, the HTTP handler determines that no transcoding is required and 

1 5 therefore does not load or use any of the HTTP transcoders. Alternatively, the IP Proxy 
18 may be configured to attempt to match the returned content type with one of its 
transcoders. In the event that an appropriate transcoder which can transcode the 
returned content type is found, the transcoder is loaded and used to transcode the 
content for transmission to the mobile device 1 2. Otherwise, the IP Proxy 1 8 may load 

20 the default transcoder or discard the received content. 

Other mechanisms for coping with missing content type information in a 
request from the mobile device 12 will be apparent to those skilled in the art. The 
particular mechanism implemented in an IP Proxy system 18 may for example be a 
default mechanism used by the IP Proxy system 18 whenever an information request 
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does not indicate an acceptable content type, dependent upon a setting in a mobile 
device user profile stored in a database accessible to the IP Proxy 1 8, or determined by 
an IP Proxy owner or operator. However, the mobile device 12 and any applications 
resident thereon are preferably configured to include accepted content type indicators in 
5 all information requests generated at the mobile device 12, in order to provide the IP 
Proxy 18 with reliable and current information regarding the type(s) of content that a 
mobile device 12 can accept. Pattern matching techniques may also be used to 
produce more complex default behaviour such as applying a transcoder to transcode all 
data to a common output type regardless of the input type. The order of such 

1 o pattern/transcoder rules may connote priority. 

As described above, there is preferably a transcoder configuration file for 
each connection handler supported by an IP Proxy system 18, or possibly a single 
configuration file shared by all connection handlers. Such a configuration file not only 
provides a mechanism for adding new transcoders as they become available, but also 

15 allows a connection handlerto quickly determine which transcoders are available in the 
IP Proxy system 18 and then effectively extend the types of content that can be 
accepted in response to an information request. 

Fig. 5 is a signal flow diagram showing the extension of accepted content 
types by an HTTP connection handler based on available transcoders. Although Fig. 5 

20 shows only those components of the IP Proxy system 18 directly involved in the 
example of an HTTP request from a mobile device 12, those skilled in the art will 
appreciate that other system components may also be present. In order to avoid 
congestion in the drawings however, such components as 30 through 48 in Fig. 2 have 
not been shown in Fig. 5. 
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In Fig. 5, an HTTP request is sent from the mobile device 12, through a 
wireless network and possibly through a WAN and appropriate gateway to the IP Proxy 
system 18. As described above, the mobile device 12 may communicate with an IP 
Proxy system 18 using a protocol other than HTTP, such as the proprietary IPPP. In 
5 such arrangements, although the connection request conforms to a particular protocol, 
the request may specify a connection type or connection handler, HTTP in this 
example, associated with a different protocol. Therefore, references to HTTP requests 
sent from a mobile device 12 should be interpreted to include both HTTP requests, if 
mobile device to IP Proxy communications are via HTTP, as well as connection 

10 requests which conform to other protocols but specify HTTP or HTTP connection 
handlers and thus are interpreted by an IP Proxy as HTTP requests. 

The connection request is received by the dispatcher 22, which 
recognizes the request as an HTTP request and loads the HTTP handler 26. In its 
Accept line, the request in this example specifies that the mobile device 12 can accept a 

15 tokenized, compressed version of Wireless Markup Language (WML) which is 
generally referred to Compiled WML or simply WMLC. The HTTP handler then uses 
this accepted content type (WMLC) to perform a lookup in the configuration file 72, 
shown in the transcoding system 28 in Fig. 5. It will be appreciated by those skilled in 
the art however, that the configuration file 72 might instead be external to the 

20 transcoding system 28, part of the HTTP handler 26, or even external to the IP Proxy 
system 18 provided that the HTTP handler can access the file. In most 
implementations, the configuration file will be stored in a data store accessible by the IP 
Proxy system 1 8, typically on the same computer system on or in conjunction with 
which the IP Proxy 18 is running. 
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The HTTP handler 26 searches the configuration file 72 to determine 
which if any of its associated transcoders outputs the requested content type, WMLC. In 
one embodiment, a lookup table which maps input content types to output content types 
for all configured transcoders is constructed when transcoders are first loaded to the IP 
5 Proxy system 18. The IP Proxy system 18 then accesses the table and determines 
which content types it can convert into the requested content type (WMLC). In Fig. 5, 
the configuration file 72 or alternatively a lookup table, includes entries for two 
transcoders, one for converting from WML to WMLC and the other for converting from 
HTML to WMLC. The HTTP handler 26 then adds the extra MIME types (WML, HTML) 

10 that it can convert to the requested type (WMLC) and submits a request to the web 
server 76. As shown in Fig. 5, the request prepared and sent by the IP Proxy 1 8 to the 
web server 76 includes WMLC, WML and HTML in its Accept line. 

The request preferably lists the accepted content types in order of 
preference. For example, since the mobile device 12 can accept WMLC, this type of 

15 content does not require transcoding and therefore preferably appears first in the IP 
Proxy request. Other content types may then be listed in order of decreasing 
transcoding complexity, for example, or based upon some other criteria. The order of 
preference of content types may also be indicated explicitly, for example using quality 
factors in the Accept line. 

20 In response to an HTTP request from the IP Proxy 1 8, the web server 76 

returns requested content, in WML format in the example in Fig. 5, to the IP Proxy 18. 
The HTTP handler 26 then determines that the returned content is WML, loads the 
appropriate WML->WMLC transcoder 74 from a local store for example, and executes 
the transcoder to convert the received content into WMLC. The WMLC content is then 
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forwarded to the mobile device 12, through the dispatcher 22. When WMLC content is 
returned by the web server 76, the HTTP handler 26 forwards the content to the 
dispatcher 22 without transcoding, whereas if HTML content is returned, an HTML- 
>WMLC transcoder would be invoked to convert the content to WMLC. Although Fig. 5 
5 shows the response to the mobile device 1 2 being handled by the dispatcher 22, similar 
protocol translation or conversion between HTTP used by the handler 26 and a 
communication protocol used by themobile device 12 may instead be performed by the 
HTTP handler 26 or another IP Proxy protocol translation/conversion module. 

As described above, if the returned content cannot be converted to the 
10 requested type, for example if the HTTP handler 26 does not have an appropriate 
transcoder or cannot determine the best transcoder to use, then the default transcoder 
is preferably used. An error message may be returned to the mobile device 12 if the 
output of the default transcoder cannot be accepted by the mobile device or the default 
transcoder is discard. 

1 5 The Accept line extension by a connection handler is in no way restricted 

to single-transcoder operations. In the example of Fig. 5, each transcoder converts 
directly from one format into the requested format. Another embodiment, a more 
extensive search of the configuration file 72 may be conducted or a more exhaustive 
lookup table may be assembled. Thus, multiple transcoders may be used to convert 

20 received content into a format or type that may be accepted by the mobile device. 

Fig. 6 is a signal flow diagram showing multiple or "chained" transcoding 
operations for an HTTP operation. As in Fig. 5, Fig. 6 shows only those components of 
the IP Proxy system 1 8 directly involved in an HTTP request from a mobile device 12 in 
order to avoid congestion in the drawings. 
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An HTTP request is sent from the mobile device 1 2 to the IP Proxy system 
1 8, possibly through one or more intervening networks and interface components. As in 
the above example, the request is received by the dispatcher 22, which recognizes the 
request as an HTTP request and loads the HTTP handler 26. The HTTP handler 26 
5 then consults the configuration file 78 searching not only for transcoders that output 
WMLC, but also for transcoders that output content types that may be input to any 
transcoder that outputs WMLC. Therefore, according to this embodiment, additional 
MIME types are appended to the header Accept line of an HTTP request based not only 
on transcoder outputs, but also on transcoder inputs. In Fig. 6 for example, the HTTP 

10 handler 26, perhaps in a first search pass through the configuration file 78, finds the 
WML->WMLC transcoder entry. The HTTP handler 26 may then repeat the 
configuration file search for any transcoders such as the HTML->WML transcoder that 
convert content into WML, which it can convert into the requested WMLC content type, 
to thereby further extend the list of accepted content types. The configuration file search 

15 may be further repeated by the HTTP handler 26, depending for example on acceptable 
delays in HTTP request processing. 

In order to avoid the delays and demand on processing resources 
associated with such multiple search passes through a configuration file, a transcoder 
content type lookup table may be used. When transcoders are first installed in an IP 

20 Proxy system 18, a comprehensive mapping table is preferably constructed to map 
received content types to possible output content types. For example, in Fig. 6, a lookup 
table entry for WMLC content would indicate that either WML or HTML can be 
converted into WMLC. Such a table would also preferably indicate that HTM L-> WMLC 
transcoding involves two stages of transcoding. The table might instead be organized 
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into single- and chained-transcoding sections, whereby if only a single transcoding 
operation is preferred, the single-transcoder part of the table including an entry for the 
WML->WMLC transcoder would be accessed. Illustratively, a chained transcoder 82 
that converts HTML to WMLC may be created from the HTML->WML and WML- 
5 >WMLC transcoders. The HTML->WML and WML->WMLC transcoders may also be 
separately invoked. 

If further transcoding operations and the associated processing operations 
and time delays are acceptable, then the HTTP handler 26 may perform a lookup of an 
accepted content type or possibly an input type for a previously identified transcoder in 

10 a chained-transcoder section of the table. Preferably, the format of the transcoding 
configuration file may be changed to represent just such a lookup table in order to 
speed up the search. This may be accomplished, for example, by specifying a path 
between content types involving multiple transcoders. 

The determination of whether multiple transcoding operations will be 

15 permitted may be made by the HTTP handler 26 either before or after the table or 
configuration file lookup operation is performed, before an HTTP request is sent to the 
web server 80, or even after the requested content is received from an information 
source 20. In the example of Fig. 6, it should be apparent that multiple transcoders may 
be invoked to convert received content into WMLC. The Accept line in the header of the 

20 HTTP request from the mobile device 12 is therefore expanded to include WML and 
HTML in addition to WMLC. As described above, the accepted formats are preferably 
listed in order of preference. Since HTML requires two transcoding operations instead 
of the single transcoding operation required to convert from WML to WMLC, WML is 
preferably listed before HTML in the Accept line of the HTTP request sent from the IP 
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Proxy 18 to the web server 80. Similarly, WMLC requires no transcoding and is 
preferably listed first in the Accept line. 

It is also feasible for the chain of transcoders to include both local and 
remote transcoding services. These remote transcoding services could be transcoder 
5 files that the IP Proxy 18 discovers, downloads and executes or they could be web 
based transcoding services which receive data in one format and return it in another, as 
described in further detail below. 

The web server 80 then returns the requested content, in HTML format in 
the example in Fig. 6, to the IP Proxy 18 in response to the HTTP request. The HTTP 

10 handler 26 determines that the returned content is HTML, loads and executes the 
HTML->WML transcoder and then loads and executes the WML->WMLC transcoder on 
the WML result of the first transcoding operation. The resultant WMLC content is then 
forwarded to the dispatcher 22 and then to the mobile device 12. If WMLC content is 
returned by the web server 80, the HTTP handler 26 forwards the content to the 

15 dispatcher 22 without transcoding, whereas if WML content is returned, the WML- 
>WMLC transcoder is invoked. 

It is contemplated that the determination as to whether multiple 
transcoding operations are allowed will be made dependent upon predetermined criteria 
such as maximum HTTP request processing time or maximum content transcoding time 

20 or processor time for example. This determination might also take a user-specified 
priority into account. If high time priority (low time delay) is assigned by the user to a 
submitted request, then single transcoder operations may be selected. Alternatively, if a 
high data priority is associated with a request, then any number of chained transcoder 
operations may be allowed in order to get the requested data back to the mobile device 
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in an acceptable format. Other criteria which may be applied by a connection handler 
include but are in no way limited to allowing chained transcoders only for relatively small 
amounts of received content, only at certain times of day, under specific current traffic 
conditions, or only when the configuration file or lookup table is stored in a local file 
5 system. Further criteria will be apparent to those skilled in the art and as such remain 
within the scope of the present application. 

In the case of a data push to a mobile device 1 2 from a push server such 
as 42 (Fig. 2), if the server pushes data content but does not specify a MIME type, then 
the default transcoder is preferably used. If the default transcoder outputs a content 

10 type that cannot be accepted by the mobile device 12, an error signal is preferably 
returned to the push server 42, which may then re-send the data to the mobile device 
1 2. The error signal further preferably indicates to the push server 42 a reason for any 
such delivery failure, such that the push server 42 may attempt to remedy the delivery 
problem if possible before the data is re-sent. Where the data could not be delivered to 

15 the mobile device 12 because no MIME type was specified and the default transcoder 
could not transcode the data into an acceptable content type for example, then the push 
server 42 may re-send the data with an appropriate MIME type. 

Processing of a server data push with a specified MIME type may depend 
upon whether or not the IP Proxy 18 knows the content types that a mobile device 12 

20 can accept. Unlike the above example of an HTTP request and response process, the 
IP Proxy 1 8 does not have a request from the mobile device 1 2 indicating an acceptable 
content type when data is being pushed to the mobile device 1 2. If the IP Proxy 1 8 does 
not know which content type(s) that the mobile device 12 can accept, then the default 
transcoder is preferably used. However, in this situation, the active connection handler 
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may instead consult the transcoder configuration file or lookup table to determine if a 
transcoder that accepts the returned content type as input is available. If an available 
transcoder is found, then it is loaded and used to transcode the received content. If 
more than one appropriate transcoder is found, then one of them, for example the 
5 transcoder having the first entry in the configuration file or the transcoder that was used 
previously, such as the transcoder that was used most recently, to transcode data for 
the particular mobile device 12 to which the content is destined, may be loaded and 
executed. A transcoder may also be selected and used on the basis of a content type 
that was previously sent to the mobile device 12. 

10 < 

External Transcoder Systems 

As described briefly above, transcoders may be loaded as needed from a 
local store on a computer system on which an IP Proxy system 18 has been 
implemented. In another embodiment, transcoders may also be loaded from an external 

15 store. Fig. 7 is a general block diagram of a communication system with an external 
transcoder system. 

The system 90 shown in Fig. 7 is similar to system 10 of Fig. 1 except for 
the external transcoder system 86. Elements common to both systems 10 and 90 have 
been described above. As shown by the dashed lines in Fig. 7, the IP Proxy system 84 

20 may communicate with the transcoder system 86 through some sort of direct 
connection such as a serial port or connection, through a WAN 1 6 such as the Internet, 
or through a LAN 88 within which the IP Proxy system 84 and the transcoder system 86 
are configured to operate. Other communication links between the IP Proxy 84 and the 
transcoder system 86 will be apparent to those skilled in the art. 
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Fig. 8 is a signal flow diagram illustrating an example HTTP operation for 
an external transcoder system such as shown in Fig. 7. As in the preceding examples, 
an HTTP request is sent from the mobile device 12 to the IP Proxy 84, indicating that 
WMLC content is accepted at the mobile device 12. The request is received by the 

5 dispatcher 22 in the IP Proxy system 84, which determines that the request is an HTTP 
request and thus forwards the request to the HTTP connection handler 94. The HTTP 
handler 94 may be substantially similar to the HTTP handler 26 in Fig. 2 for example, 
although it operates somewhat differently than handler 24 to load content transcoders. 
The HTTP handler 94 intercepts the HTTP request from the mobile device 12 and may 

1 o then refer to a transcoder configuration file 92 or a lookup table as described above to 
determine whether or not any transcoders are available to convert other types of 
content into a type that is acceptable at the mobile device 12. If entries corresponding to 
one or more appropriate transcoders are found in the configuration file 92 or lookup 
table, then the HTTP handler 94 preferably includes any further content types in a 

15 request that is sent to an information source such as web server 76. Web server 76 
processes the request from the IP Proxy system 84 and returns WML content to the 
HTTP handler 94. These operations are substantially as described above in the 
preceding examples. 

When the WML content is received by the HTTP handler 94, it is 

20 preferably stored in a file system or other data store 98 while the appropriate transcoder 
is loaded. In the example of Fig. 8, the HTTP handler 94 requests the required WML- 
>WMLC transcoder from the transcoder system 86. Although this request is shown in 
Fig. 8 as an HTTP request from the HTTP handler 94, it should be apparent that other 
transfer mechanisms might instead be used by an IP Proxy system 84 to retrieve a 
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transcoder from a remote transcoder system 86. For example, if the IP Proxy system 
84 communicates with the transcoder system 86 via a LAN 88 (Fig. 7), then a LAN 
protocol or data access and transfer scheme could be invoked by the HTTP handler 94 
in order to retrieve any required transcoders. In Fig. 8, the transcoder system 86 locates 
5 the requested WML->WMLC transcoder among its available transcoders 96 and returns 
the requested transcoder to the IP Proxy system 84. 

Regardless of the particular transcoder transfer mechanism implemented, 
the IP Proxy system 84, or in the example of Fig. 8 the HTTP handler 94, receives and 
loads the returned WML->WMLC transcoder, as indicated at 100. The previously 

1 o received and possibly stored WML content may then be processed by the transcoder 
1 00 to transcode the WML content into WMLC content acceptable by the mobile device 
12, and a response containing the transcoded content is returned to the mobile device 
12 by the dispatcher 22. 

If chained transcoder operations are enabled, then more than one 

15 transcoder request may be made by the IP Proxy system 84 to the transcoder system 
86. Multiple transcoders may instead be requested in a single request to the transcoder 
system 86. Processing of previously received content for chained transcoder operations 
may proceed either as each required transcoder is loaded by the IP Proxy system 18, 
with intermediate transcoded content possibly being stored in a file system or data store 

20 such as 98, or only when all required transcoders have been loaded. 

When a transcoding operation is complete, a transcoder loaded from the 
external system 86 is preferably stored locally by the IP Proxy system 84 in order to 
avoid subsequent requests to the external transcoder system 86 for the same 
transcoder. Retrieval and loading of a transcoder from a local or internal store in the IP 



WO 03/007617 PCT/CA02/01072 

Proxy system 84 will typically be completed much faster than a request to a remote 
system and reduces traffic on the communication link between the IP Proxy system 84 
and the transcoder system 86. In such IP Proxy systems, the active connection handler, 
which is the HTTP handler 94 in Fig. 8, preferably determines whether a required 
5 transcoder is stored in a local data store before requesting the transcoder from the 
external transcoder system 86. Depending upon the amount of available storage, 
transcoders may be stored indefinitely or for a certain predetermined period of time. 
Other memory management schemes, such as over-writing stored transcoders on an 
LRU basis for example, may also be used when memory resources are limited. 

10 The configuration file 92 or transcoder lookup table may be adapted for 

external transcoder loading by including an indication of the location of a transcoder in 
the configuration file or table entry for the transcoder. The file 92 or table is preferably 
updated if a transcoder is stored to, or overwritten in a local memory, such that the 
active handler can determine from the initial lookup operation whether the transcoder 

15 must be loaded from the external transcoder system 86. When a transcoder has not 
been or is no longer stored locally, then the file 92 or lookup table preferably indicates 
from where the transcoder may be retrieved. For a transcoder that may be retrieved 
through an HTTP connection, the corresponding file or table entry may indicate the IP 
address of the transcoder system 86, whereas a network address may be specified in 

20 the configuration file or lookup table when a LAN connection is used. 

It is also contemplated that more than one external transcoder system 
may be implemented in a communication system such as 90. In such an arrangement, 
the configuration file 92 or lookup table would preferably include entries for all 
transcoders that are available to an IP Proxy system 84 through all of the external 



33 



WO 03/007617 PCT/CA02/01072 

transcoder systems with which it can communicate. An IP Proxy 84 may thereby 
download transcoders from any of a number of transcoder systems via direct or network 
connections. Overall operation of an IP Proxy system 84 with multiple transcoder 
systems would be substantially as described above, except that different transcoder 
systems may be accessed, possibly using different transfer mechanisms and 
communication protocols, for each data transcoding operation. Chained transcoding 
operations may also potentially involve communication with different transcoder 
systems. 

The configuration file 92 or lookup table is preferably arranged to facilitate 
a simple resolution scheme when a particular type of transcoder is available from more 
than one transcoder system. Although an IP Proxy system 84 may be able to access 
multiple transcoder systems, an owner or administrator of an IP Proxy system 84 may 
designate one of these transcoder systems as a preferred or default system from which 
the IP Proxy 84 first attempts to download a transcoder. The order of preference of 
transcoder systems for any transcoder available from more than one transcoder system 
may for example be reflected in the order of configuration file or lookup table entries. If 
the file or table is arranged by transcoder type, then entries corresponding to the most 
preferred sources for a particular transcoder are preferably listed before entries 
associated with other transcoder systems. The configuration file or lookup table may 
instead be arranged according to transcoder system, with all entries for the default or 
preferred transcoder system occurring first. In both these example arrangements, an IP 
Proxy system 84 will preferably attempt to load a particular transcoder from its preferred 
source before accessing any other sources. 

It should be apparent from the foregoing description that if a transcoder in 

34 



WO 03/007617 PCT/CA02/01072 

the configuration file or lookup table could not be loaded by an IP Proxy system 84, then 
an error may be returned to the mobile device 12 and possibly an information source 
20, particularly when the information source is attempting to push content to the mobile 
device 12. Failure to load a transcoder may also be resolved by finding alternative 
5 transcoders or chaining of transcoders. Another method to resolve transcoder 
problems is to modify the accepted line to remove the data type that caused the 
problem, and resubmit the request to the web server or information source 20. 

As described above, new transcoders may be registered with an IP Proxy 
system 84 by adding a corresponding entry to the configuration file 92 or a transcoder 

10 lookup table. Therefore, when a new transcoder is added to any external transcoder 
system, the configuration file 92 or lookup table in each IP Proxy system 84 that may 
download transcoders from the transcoder system is preferably updated accordingly. 
This may be accomplished for example by configuring transcoder systems to send 
update messages to the IP Proxy systems 84 when new transcoders are added. A 

1 5 transcoder system may instead append an update message or indicator to responses to 
requests from an IP Proxy system 84 following the addition of a new transcoder. 
According to this scheme, an update message or indicator may be appended to the 
response to an IP Proxy system 84 the first time any transcoder is requested from a 
transcoder system after a new transcoder has been added. An IP Proxy transcoding 

20 configuration file or lookup table may also be kept current with one or more external 
transcoder systems by executing a discovery routine, whereby a registry of available 
transcoders is periodically queried to "discover new transcoders as they become 
available. 

Fig. 9 shows a further signal flow diagram for an external transcoder 
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system. In Fig. 9, not only the transcoder system 86, but also the configuration file 1 02 
is external to the IP Proxy system 84 and therefore may be shared among multiple IP 
Proxy systems. Communications between an IP Proxy 84 and the configuration file 1 02 
may be via a direct connection or a network connection, and may be different for 
5 different IP Proxy systems. For example, the configuration file 1 02 may be maintained 
by an owner or operator of a particular IP Proxy system which is linked to the 
configuration file by a direct communication, whereas other IP Proxy systems' may 
communicate with the configuration file 102 through local or wide area network 
connections. As above, the configuration file 102 may instead be implemented as a 

10 lookup table. The configuration file 102 may thus be considered a registry, with which 
one or more external transcoder systems such as 86 register available transcoders. 

The operations outlined in Fig. 9 will now be described in detail. When an 
HTTP request is received by the dispatcher 22 in the IP Proxy system 84, it is forwarded 
to the HTTP handler 94, which as described above determines if any additional content 

•15 types can be transcoded into the mobile device-compatible WMLC format. In the 
example of Fig. 9 however, the configuration file 102 is remote from the IP Proxy 
system 84. If the configuration file 102 is accessible via HTTP, then the HTTP handler 
94 manages the transcoder lookup function with the configuration file 102. If the 
configuration file 1 02 is not adapted for HTTP, then a different connection handler may 

20 be invoked to facilitate the transcoder lookup or configuration file search. 

Depending upon the transcoders available to the IP Proxy 84, the HTTP 
handler 94 may expand the accepted content types in the request from the mobile 
device 12 to include the additional content types that may be transcoded into WMLC 
format acceptable at the mobile device 1 2. As above, it is assumed that the web server 
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76 from which content is requested returns WML content to the HTTP handler 94. One 
embodiment, the transcoding system 86 enables remote transcoding of content. Instead 
of requesting and loading a WML->WMLC content transcoder from the transcoder 
system 86, the HTTP handler 94 (or another connection handler, depending on the 
5 particular transcoder system and the transfer schemes it supports) transfers the WML 
content to the transcoding system 86. Within the transcoding system 86, the 
appropriate WML->WMLC transcoder 104a is executed and the WML content is 
transcoded into WMLC format. The WMLC content is then returned to the HTTP 
handler 94, or to another connection handler if IP Proxy 84 to transcoder system 

10 communications do not use HTTP. When the WMLC content is returned by the 
transcoding system 86 and received by the HTTP handler 94, possibly through another 
connection handler which communicates with the transcoding system 86, it is forwarded 
to the dispatcher 22. The dispatcher 22 then prepares a response including the WMLC 
content and sends the response to the mobile device 12. The HTTP handler 94 may 

15 instead prepare the response, which would then be translated (if necessary) by the 
dispatcher 22 to conform to a communication protocol or scheme used by the mobile 
device 1 2. Illustratively, the WML content returned by the web server 76 may be stored 
by the HTTP handler 94 in case a data transfer or transcoding error occurs. Local 
storage of the WML content allows an IP Proxy system 84 to re-submit the content for 

20 transcoding,* to the same transcoder system 86 or a different transcoder system, without 
first having to request the content from the web server 76. 

In the system of Fig. 9, it is contemplated that the transcoder system 86 
and configuration file 102 may also communicate with each other to ensure that the 
configuration file 1 02 accurately indicates which transcoders are available. One of the 

37 



WO 03/007617 PCT/CA02/01072 

update schemes described above may be used to ensure that the configuration file 
remains current. A configuration file may be associated with a particular type of 
connection, such as HTTP connections and thus HTTP connection handlers. If a 
configuration file 102 is associated with a particular transcoder system 86, then the 
5 configuration file may be resident within the transcoding system 86. If multiple 
transcoding systems are implemented, a shared configuration file storing transcoder 
entries for the transcoders available in all transcoder systems may simplify the 
transcoder lookup performed by a connection handler. An IP Proxy system 84 need 
then only consult a single configuration file to determine if appropriate transcoders are 

10 available from any transcoder systems with which it can communicate. This single 
configuration file/server could also support protocols to allow external transcoding 
servers to register. This registration process could add a list of available transcoders to 
the single configuration file, for example. 

External transcoder systems 86 therefore include download systems from 

1 5 which transcoders may be downloaded by an IP Proxy system 84 and executed locally 
(see Fig. 8) and remote transcoding systems to which content is sent for transcoding at 
the transcoding system (see Fig. 9). In another embodiment, a "hybrid" transcoder 
system incorporates aspects of both these types of transcoder systems. When a hybrid 
transcoder system is available to an IP Proxy system 84, the IP Proxy system 84 may 

20 either download a required transcoder from the transcoder system or send content to 
the transcoder system to be transcoded remotely. The selection of transcoder download 
or remote transcoding may be dependent, for example, upon the amount of data to be 
transcoded, the complexity of the transcoding (single or chained operations), or other 
criteria. 
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External Connection Handler Systems 

A further extension of the concept of a distributed IP Proxy system with 
external, possibly shared components is shown in Fig. 1 0. Fig. 1 0 is a block diagram of 
5 a communication system with an external transcoder system 86 and an external 
connection handler system 1 08. The system 1 1 0 of Fig. 1 0 is substantially the same as 
the system 90 in Fig. 7, except that connection handler system 1 08 is external to the IP 
Proxy system 106. The IP Proxy system 106 can download connection handlers from 
the connection handler system 108 via a direct connection, a LAN 88, or a WAN 16 

10 such as the Internet. 

Fig. 1 1 is an example signal flow diagram for the system of Fig. 10. In Fig. 
1 1 , the connection handler system 1 08, the transcoder system 86, and the configuration 
file 102 are all external components and therefore may be shared among multiple IP 
Proxy systems 1 06. These external components may be implemented for access by all 

15 IP Proxy systems 106 owned and/or operated by a company, an Internet Service 
Provider (ISP) or an Application Service Provider (ASP) for example, such as through a 
company intranet, dial-up connection or other communication arrangement. The 
connection handler system 108, the transcoder system 86, and the configuration file 
102 might instead be publicly accessible to any IP Proxy 106 through the Internet. 

20 Those skilled in the art will appreciate that an IP Proxy system such as 106 may 
potentially have access to both private, possibly corporate-, ISP- or ASP-based external 
components, as well as public connection handler systems, configuration files or 
transcoder systems. As above, communications between an IP Proxy 1 06 and external 
components may be via a direct connection or a network connection, and may be 
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different for different IP Proxy systems. 

By way of example, the operations associated with a system such as 1 1 0 
will be described below for an HTTP request. When an HTTP request is received by the 
dispatcher 22 in the IP Proxy system 106, an appropriate handler may have to be 

5 downloaded from the connection handler system 108, unless the handler is already 
resident on the IP Proxy 106 as described in further detail below. This is shown in Fig. 
1 1 as a handler request, which may be processed through a resident handler 1 1 2 such 
as a TCP handler that is compatible with the connection handler system 108. This 
resident handler 112 will normally be provided locally on an IP Proxy system 108 in 

10 order to enable communication between an IP Proxy system and an external 
connection handler system 108. However, the handler may instead be downloaded by 
an IP Proxy system 106 from a connection handler system, preferably through an 
automated download procedure. 

The handler 112 then requests the appropriate connection handler, an 

15 HTTP connection handler in this illustrative example, from the external connection 
handler system 108. If the required connection handler is unavailable or cannot be 
downloaded, then an error may be returned to the mobile device 12. If the required 
HTTP connection handler 108a is returned by the connection handler system 108 
however, it is loaded by the IP Proxy system 106. The dispatcher then forwards the 

20 original HTTP request from the mobile device 1 2 to the HTTP handler 1 08a. The HTTP 
handler 1 08a may determine whether any additional content types can be transcoded 
into the mobile device-compatible WMLC format. As described above, this 
determination may be made by performing a transcoder lookup in a local configuration 
file or lookup table or external configuration file 1 02 or lookup table. If the configuration 
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file 102 is accessible via HTTP, then the HTTP handler 108a manages the transcoder 
lookup; otherwise, a different connection handler may be invoked, possibly after a 
further connection handler download operation, to facilitate the transcoder lookup or 
configuration file search. 
5 Depending upon the result of the transcoder lookup, the HTTP handler 

108a may expand the accepted content types in the request from the mobile device to 
an information source such as a web server 76. As above, it is assumed that the web 
server 76 returns WML content to the HTTP handler 1 08a. The returned WML content 
may be transcoded into WMLC content by invoking a WML->WMLC transcoder stored 

10 in a memory in the IP Proxy system 106, by downloading a WML->WMLC transcoder 
from an external transcoder system and then invoking the transcoder at the IP Proxy 
system 106, or by sending the WML content from the IP Proxy system 106 to an 
external transcoder system 86 for remote transcoding by a WML->WMLC transcoder 
1 04a in the transcoding system 86. Although a single transcoder operation is shown in 

15 Fig. 1 1 , chained transcoding operations and any necessary associated downloading or 
transfer operations may also be performed. When WMLC content is then returned to 
the HTTP handler 1 08a, possibly through another connection handler if IP Proxy 1 06 to 
transcoder system 86 communications do not use HTTP, a response including the 
WMLC content is prepared and sent to the mobile device 1 2 through the dispatcher 22. 

20 The external connection handler system 1 08 provides for an extension of 

the types of connection through which an IP Proxy system 1 06 may access data to be 
sent to a mobile device 12. Once downloaded from an external connection handler 
system, a connection handler such as HTTP handler 108a may be stored by an IP 
Proxy system 106 to a local data store. In such systems, the dispatcher 22 would 
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preferably access the local store to determine if a required handler is already resident 
within the IP Proxy system 1 06. Subsequent downloads for previously used connection 
handlers can thereby be avoided. Download operations may be further reduced by 
providing one or more of the most commonly used connection handlers in a local 
5 memory on initialization of an IP Proxy system 1 06, such that only less frequently used 
connection handlers are downloaded from an external connection handler system as 
needed. 

Similar to the external transcoding system described above; an external 
connection handler system may be either a download system, as shown in Fig. 1 1 , or a 

10 remote connection handling system, in which connection handlers are invoked and- 
executed on the connection handler system instead of being downloaded for execution 
on the IP Proxy system 106. In the example of an HTTP request, when remote 
connection handling is enabled, a request from the mobile device 12 may be either 
delegated or handed off to the external connection handler system. 

15 Fig. 12 is a signal flow diagram illustrating delegation of an information 

request to an external connection handler. In the example of Fig. 1 2, a request from the 
mobile device 12 is received by the dispatcher 22 in the IP Proxy system 106a and 
forwarded to the resident handler 112. Although referred to as a resident handler, the 
handler 1 12 may have been downloaded to the IP Proxy system 106a from an external 

20 connection handler system. The resident handler 112 may then consult a transcoder 
configuration file 72 and extend the accepted content types in the request. It will be 
apparent from the foregoing description that an external configuration file may also be 
implemented. The resident handler 112, which as described above is compatible with 
the connection handler system 1 08, forwards the request, possibly having an extended 



42 



WO 03/007617 PCT/CA02/01072 

Accept line, to the connection handler system 1 08. The connection handler system 1 08 
determines that the request is an HTTP request and invokes the HTTP connection 
handler 108a. The request is thereby delegated to the external handler 108a, which 
sends an HTTP request to the information source, in this example the web server 76, 
5 and receives returned WML content. The WML content is then returned to the resident 
handler 1 1 2, which transcodes the WML content into mobile device-compatible WMLC 
content using a WML->WMLC transcoder 74. This transcoding could instead involve 
chained transcoders and/or external transcoders as described above. The resultant 
WMLC content is then returned to the mobile device 12 via the dispatcher 22. 

10 In Fig, 12, extension of accepted content types and content transcoding is 

managed within the IP Proxy system 106a. Fig. 13 is a signal flow diagram showing a 
variation of the request delegation of Fig. 12. In Fig. 13, a request from the mobile 
device 12 is forwarded to the resident handler 1 12 by the dispatcher 22. The resident 
handler 112 then forwards the request to the connection handler system 108, which 

15 starts the HTTP handler 1 08a. The HTTP handler 1 08a consults the configuration file 
1 02 or lookup table to determine which if any transcoders may be available to transcode 
other content types into the requested type, WMLC, and then modifies the request to 
include these other content types, WML and HTML in this example. The modified 
request is sent to the web server 76, which returns WML content. The returned WML 

20 content is then sent to an appropriate WML->WMLC transcoder 104a in a transcoder 
system 86, and the transcoded content is returned to the HTTP handler 1 08a and then 
to the resident handler 112 in the IP Proxy system 106a. A response. including the 
W MLC content is sent to the mobile device from the handler 112 through the dispatcher 
22 to complete the operation. 
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Fig. 14 is a signal flow diagram showing hand-off of a request to an 
external connection handler. In a hand-off scheme, the IP Proxy system 106c forwards 
the request via its resident handler 112 to the external handler system 108. The 
connection handler system 1 08 and the appropriate handler, HTTP handler 1 Q8b in this 
5 example, then manage the remainder of the information request/response operation. 
Once the request is handed off to an external connection handler system, the IP Proxy 
system 106c preferably has no further involvement in the operation. 

Referring now in detail to Fig. 14, a request from the mobile device 12 is 
sent to the connection handler system 1 08. The connection handler system 1 08 invokes 

10 the appropriate handler illustratively HTTP handler 1 08a, which may modify the request 
to include further content types and sends the request to the information source (web 
server 76), receives content from the information source, and invokes any required 
transcoding operations in the external transcoding system 86, substantially as described 
above in conjunction with Fig. 1 3. Instead of returning the transcoded WMLC content to 

15 the IP Proxy system 1 06c however, the external connection handler, system preferably 
includes a mobile device protocol handler 1 08c, which sends a response to the mobile 
device 12. 

When a mobile device protocol is different than the request protocol such 
that different handlers are invoked for communication with an information source and 
20 the mobile device as shown in Fig. 14, the HTTP handler 108b and the mobile device 
protocol handler 1 08c are effectively chained, similar to transcoder chaining described 
above. Although shown as part of the Same connection handler system 1 08, the HTTP 
handler 108b and mobile device protocol handler 108c may instead be associated with 
different connection handler systems. The connection handler system 108 may, for 
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example, download the mobile device protocol handler 108c from another connection 
handler system or invoke the mobile device protocol handler at the remote system. It 
will be apparent from the foregoing description that the mobile device protocol handler 
108c in Fig. 14 is functionally similar to the dispatcher 22 in that it translates between 

5 connection handler and mobile device communication protocols when necessary. 

Connection handlers in the same or different connection handler systems 
may also be chained in order to process an information request from mobile device 1 2, 
for example to request the information from an information source or to manage 
transcoding of returned content. Any connection handler chaining operations may 

1 o involve delegation or hand-off, and may preferably be controlled by either a connection 
handler system or an IP Proxy system at which a request was originally received. 

It is also contemplated that more than one connection handler system 
may be available to any IP Proxy system. As described above for external transcoder 
systems, external connection handler systems may be registered in one or more 

15 registries that may be consulted by an IP Proxy system to find available connection 
handlers. Where connection handler chaining is required, connection handler systems 
may also access the registry to locate a particular type of connection handler in another 
connection handler system. A registry scheme would also simplify dynamic connection 
handler management by facilitating discovery functionality to allow IP Proxy systems 

20 and connection handler systems to discover new connection handlers and systems as 
they become available. In systems with multiple external connection handler systems, 
an IP Proxy system may effectively become a load balancing module that may distribute 
incoming mobile device requests among different connection handlers. 

Connection handlers have been described above primarily in the context 
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of communication or connection protocols. However, it also contemplated that handlers 
may be implemented for other functions or services, including for example encryption, 
compression, user authentication, and state management. Such "service handlers" may 
possibly be embedded with connection handlers, but would preferably be distinct 

,5 modules that may be chained with connection handlers as needed. A chaining 
mechanism provides for more flexibility in connection management and request 
processing in that a basic connection handler may be chained with as many service 
handlers as desired to customize a connection or request/response operation. A 
connection handler system may include service handlers, and may also or instead 

10 accomplish connection handler and service handler chaining through downloading or 
remote execution of sen/ice handlers in one or more further service handler systems. 

Example Implementation 

" An example implementation of an IP Proxy system will now be described. 
15 Fig. 15 is a block diagram showing an IP Proxy system implemented in a secure 
network. 

. The system 120 in Fig. 15 includes a mobile device 12 that operates 
within a wireless network 1 4. Through a gateway 1 5, the mobile device can receive and 
preferably also send data over a WAN 1 6 such as the Internet. These elements of the 
20 system 120 are substantially the same as similarly labelled elements in Fig. 1 . In the 
system 120 however, the IP Proxy system 124 is configured within a private network 
such as a corporate network 130, behind a security firewall 127, and communicates 
with the gateway 15 through a network server computer 122. In a particular example 
embodiment, the network server 122 is associated with an email system 128. Two 
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information sources, an internal source 126 and an external source 132, are also shown 
in Fig. 15. 

The network server 1 22 preferably enables secure communication to the 
mobile device 1 2, as indicated by the encryption and decryption blocks 1 22a and 1 22b. 
5 The network server 1 22 encrypts any communications directed to a mobile device 1 2. 
The intended recipient mobile device 1 2, using a secret key stored therein, can decrypt 
encrypted communications from the network server 122. A mobile device 12 similarly 
encrypts any information sent to the network server 1 22, which can be decrypted by the 
decryption module 1 22b. Those skilled in the art of cryptography will appreciate that the 

10 keys and encryption algorithms used at the network server 122 and mobile device 12 
are preferably chosen so that it would be computationally infeasible to decrypt 
encrypted information without the required secret key. One preferred encryption 
scheme is triple-DES (Data Encryption Standard). 

Key distribution between a network server 122 and a mobile device 12 

15 may be accomplished via a secure connection such as a secure physical connection 
between the mobile device 12 and the network server 122, or between the mobile 
device 12 and another computer within the corporate network. Known public key 
cryptography techniques may instead be used for key distribution. In a public key 
scheme, a public key is used to encrypt information in such a way that the encrypted 

20 information may be decrypted using a corresponding private key. The public key is 
stored by, and may be retrieved from, a publicly accessible key repository commonly 
referred to as a certificate authority or CA, whereas the private key is stored only at a 
mobile device or system with which the public key is associated. Thus, a network server 
1 22 or any other sender that wishes to send encrypted information to a mobile device 
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12 may retrieve the mobile device's public key from a CA and use the public key to 
encrypt information destined for the mobile device 1 2. A mobile device 1 2 may similarly 
obtain a network server's public key from a CA and use the public key to encrypt 
communication signals to be sent to the server. 

5 Regardless of the particular key distribution scheme and encryption 

techniques used, encrypted communications between a mobile device 1 2 and network 
server 122 may be used, for example, where corporate or other private information is to 
be accessed using a mobile device. Consider the example of the internal information 
source 126 within the security firewall 127, described below with reference to Fig. 16, 

1 o which is a signal flow diagram illustrating a corporate data access operation. In keeping 
with the above illustrative example operations, Fig. 16 shows an HTTP-based data 
access operation. 

In Fig. 16, an HTTP request is encrypted at the mobile device 12, 
preferably using a strong encryption routine such as triple-DES (3DES), before it is sent 

1 5 to the network server 1 22 through the wireless network 1 4 of Fig. 1 5 and possibly other 
intermediate networks or components, such as the gateway 15 and WAN 16 shown in 
Fig. 15. The encrypted request is then received by the network server 122 and 
decrypted in the decryption module 1 22b. The decrypted request is forwarded to the IP 
Proxy system 124, which may proceed to process the request substantially as 

20 described above. The active handler, the HTTP handler 26 in this example, may consult 
the configuration file 72 or transcoder lookup table and expand the accepted content 
types to include content types that can be transcoded into the format(s) that can be 
accepted by the mobile device 12. A request, possibly including further content types, is 
then sent by the HTTP handler 26 to the information source 126, which then returns 
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requested information, in WML format in this example. An appropriate transcoder 74 is 
loaded and invoked by the HTTP handler 26 if necessary and the requested content, 
preferably in a format requested by the mobile device 12, is returned to the network 
server 1 22 through the dispatcher 22. The network server 1 22 then encrypts the content 

5 received from the IP Proxy system 124 in its encryption module 122a and sends the 
encrypted content in a response to the mobile device 1 2. In some implementations, the 
protocol conversion or translation operations associated with the dispatcher may 
instead be performed by the network server 122. 

The information source 126 may be a computer system or data store 

1 o preferably configured for operation on the private network 1 30, such as a file server or 
other data store accessible through the network 130. In the example of a corporate 
network, the information source 126 may include confidential or otherwise sensitive 
information that an owner of the network 130 strives to keep private. The security 
firewall 127 is intended to prevent unauthorized access to private network components 

15 including the information source 126. In some situations, the very existence of 
information stored at the information source must remain confidential. The encryption of 
the request from the mobile device as shown in Fig. 1 6 prevents an unauthorized party 
from determining the contents of the request without breaking the encryption, which as 
described above is not computationally feasible for strong encryption schemes such as 

20 3DES. The request remains encrypted until received by the network server 122 and 
decrypted, behind the security firewall 1 27, as indicated at 134 in Fig. 1 6. The request is 
therefore virtually as secure as a request sent from a computer system on the network 
130. 

Once decrypted, the request is processed by the IP Proxy 124 and 
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information source 126 as described above. However, encryption of the requested 
content by the encryption module 1 22a in the network server 1 22 before it is sent to the 
mobile device 12 similarly ensures that the content can only be viewed by the mobile 
device 12. Confidential corporate information therefore remains encrypted and thus 

5 secure until received and decrypted at the mobile device 12, thereby effectively 
extending the security firewall 127 to the mobile device 12. Both the request and the 
information returned to the mobile device in response thereto are secure. 

In known remote data access schemes such as WAP, gateway systems 
which provide for data access using mobile devices are normally located outside 

10 corporate or private premises, at the location of a service provider for example. Any 
confidential or sensitive information encrypted at the private premises is decrypted at 
the gateway system, outside the corporate firewall, and then re-encrypted before being 
sent to the destination mobile device or devices. The information is therefore in the 
clear at the gateway system and thus accessible by an owner or operator of the 

15 gateway system. Furthermore, the owner or operator of a private network from which 
the information was sent typically has no control over security arrangements at the 
gateway system, such that the information is vulnerable to attacks on the gateway 
system. 

The arrangement shown in Figs. 15 and 16 wherefore provides secure 
20 remote access to private, confidential or otherwise sensitive information. Information is 
encrypted from end-to-end between the network server 122 and any mobile device 1 2. 
Any level of security may be implemented, at the security firewall 127 to protect 
confidential information stored at an information source such as 126, and when 
encrypted by the network server 122, information is not decrypted at any intermediate 
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point before being received at a mobile device 12. The information is in the clear only 
"inside" the point 134, behind the security firewall 127, and on the mobile device 12. 
Security arrangements such as password or passphrase control are also preferably 
implemented at the mobile device 12 to prevent an unauthorized user from using the 

5 mobile device or decrypting received encrypted information. For example, computer 
workstations may be protected by password-deactivated system locking and access to 
a corporate network 130 is normally protected by login passwords. Similarly, a 
password may be required to use a mobile.device 12, while a different passphrase may 
be necessary to decrypt any encrypted information stored on the mobile device 12. A 

1 o mobile device 1 2 and information stored thereon is thereby just as secure as a network 
workstation and information stored on a network. Such techniques as limited password 
or passphrase entry retries, mobile device 12 or mobile device memory reset after a 
predetermined number of failed password/passphrase entries, dynamic and possibly 
random password/passphrase updates and the like may be used to further improve 

15 mobile device security. 

For an external information source 1 32 (Fig. 1 5), a data access operation 
is substantially the same as shown in Fig. 16, except that the information source is 
outside the firewall 127. The request and response exchange between the mobile 
device 12 and the network server 122 may be encrypted, but information exchanged 

20 with the information source 132 may be unsecure. If the information provided by the 
information source 1 32 is not private or confidential, then unsecure exchange between 
the IP Proxy system 124 and the source 132 will be sufficient for most purposes. 

One possible measure to improve the security of information being 
requested from an external source 1 32 is to secure the communications between the IP 
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Proxy system 1 24 and the source 1 32. For example, the IP Proxy system 1 24 may be 
adapted to support Secure HTTP (HTTPS), Secure Sockets Layer (SSL) or other 
secure communication schemes in order to securely access information at the 
information source 132. Information from the source 132 may thereby be securely 

5 transferred to the IP Proxy system 124 and is then protected by the security firewall 
1 27. Encrypted information may be decrypted by the I P Proxy system 1 24, by the active 
connection handler for example, and transferred to the network server 1 22, which then 
encrypts the information for transmission to the mobile device 12. As above, information 
is only in the clear behind the firewall 127. Alternatively, a secure communication 

1 o session may be established between the mobile device 1 2 and source 1 32 through the 
IP Proxy 124. In the system of Fig. 15, communications between the mobile device 12 
and network server 122 would then be double-encrypted. 

As shown in Fig. 15, the network server 122 is also associated with the 
. email system 128. In one embodiment, the network server 122 provides for sending 

15 data items from the email system 128 to mobile device 12. One such system is 
described in detail in United States Patent 6,219,694, entitled "System And Method For 
Pushing Information From A Host System To A Mobile Data Communication Device 
Having A Shared Electronic Address", and issued to the assignee of the present 
application on April 17, 2001. The complete disclosure of this patent is hereby 

20 incorporated into this application by reference. 

Since the network server 122 is also associated with the IP Proxy system 
124, integrated functionality between the email system 128 and the IP Proxy system 
124 may be possible. For example, the IP Proxy system 124 may use encryption 
functionality of the network server 122 as well as a transport mechanism via which the 
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network server 122 communicates with the mobile device 12. Other functions of the 
network server 1 22, such as data compression, for example, may similarly be exploited 
by an IP Proxy system 124 to improve the efficiency of use of wireless communication 
resources. As described briefly above, content destined for a mobile device 1 2 may be 

5 addressed to the mobile device using an email address in the email system 128 
associated with the mobile device user. In this example, content forwarded to the 
mobile device by the IP Proxy system 124 may also be stored in the user's mailbox on 
email system 1 28 by the network server 1 22, as indicated in Fig. 1 5, to thereby provide 
both a record of IP Proxy operations and a stored copy of any forwarded content. Other 

10 integrated functions may include but are in no way limited to email-based content 
requests from mobile devices and addressing of mobile device-destined information by 
the IP Proxy system 124 using an email address on the email system 128. Still further 
integrated functions may be enabled where a network server 122 or the IP Proxy 
system 124 is associated with any other services. 

15 It will be appreciated that the above description relates to preferred 

embodiments by way of example only. Many variations on the invention will be 
appreciated by those knowledgeable in the field, and such variations are within the 
scope of the invention as described, whether or not expressly described. For example, 
embodiments of the invention have been described primarily in the context of an IP- 

20 based system. Similar proxy systems for other types of communication systems are 
also contemplated within the scope of the invention. Other types of connections, 
connection handlers and transcoders than those described above will also be apparent 
to those skilled in the art. 

Depending upon the particular implementation of a remote data access 
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system and the features to be supported, not all of the elements shown in Fig. 2 are 
required. Where push services are not supported for example, the proxy system will not 
include push services 30. 

The invention is also in no way limited to content type indication using 
5 MIME types. MIME types are useful in conjunction with the instant invention, but are not 
required to practice the invention. Other content type indicators may be substituted for 
MIME type to indicate the type or format of requested or received content. 

Although the transcoders described above convert between well-known 
information types or formats, custom transcoders could be developed and implemented 
10 for virtually any information format, including for example application program file types 
and proprietary formats. As described above, a proxy system in accordance with the . 
instant invention is preferably configurable and new content transcoders may be added. 

It is also possible that information content from an information source may 
include multiple different content types, not just a single content type as described 
15 above. For such multiple-type content, transcoders may be selected, for example, to 
transcode the content into a single content type, or into multiple content types accepted 
at a mobile device. Selection of transcoders may be controlled according to any of the 
transcoder selection schemes described above. In the case of transcoder selection by 
a mobile device or information source, a list of transcoders for any or each part of 
20 multiple-type information type content may be specified in a connection request, a 
response to a request, or a push request. A respective transcoder may be selected and 
used for each part of the information content having a particular content type. 

When any part of multiple-type information content cannot be transcoded 
as desired or required, where a suitable transcoder is not available for example, only 
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other parts of the information content might be transcoded and sent to a mobile device. 
Alternatively, a default transcoding operation as described above may be used to 
transcode parts of multiple-type content. Non-transcoded parts of multiple-type content, 
or possibly all of the multiple-type content, could instead be replaced with a link or other 

5 information that may be used to subsequently access the information content or parts 
thereof, and sent to a mobile device. Information indicating the multiple content types 
and/or required or recommended transcoders could also be sent to the mobile device. 
The information content or parts thereof may then be retrieved by the mobile device by 
submitting a connection request or possibly further transcoding instructions or an 

10 alternate transcoder selection to an IP Proxy system. 

Furthermore, a proxy system may be implemented in any network, not 
only in a corporate network as shown in Fig. 1 5. Installation of a proxy system in an ISP, 
ASP, or Virtual Network Operator (VNO) system would provide for secure remote 
access to network information and secure transfer of information between any network 

15 users, including transfers between mobile devices of ISP, ASP or VNO users. 

Although the invention has been described in detail with reference to 
certain illustrative embodiments, variations and modifications exist within the scope and 
spirit of the invention as described and defined in the following claims. 
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What is claimed is: 

1 . A system for providing data access between an information source and 
• a mobile communication device, the system comprising: 

a transcoding system comprising a plurality of transcoders, each transcoder 
5 operable to transcode information content from a respective first content type into a 
respective second content type; and 

a first network device in communication with the transcoding system and 
comprising a connection handler system, the connection handler system operable to 
receive connection data for a connection between the information source and the 
10 mobile communication device and to select a corresponding connection handler 
operable to select one or more transcoders from the plurality of transcoders to 
transcode the information content. 

2. The system of claim 1 , wherein the connection handler system 

15 comprises a connection handler directory, the connection handler directory storing 
connection handler data. 

3. The system of claim 2, wherein the connection handler data comprises 
connection handler data associated with at least one connection handler. 

20 

4. The system of claim 2, wherein the connection handler data comprises 
a network address specifying the location of a connection handler. 

5. The system of claim 4, wherein the connection handler system is 



56 



WO 03/007617 PCT/CA02/01072 

operable to access the location specified by the network address, retrieve the 
connection handler, and store connection handler data associated with the 
connection handler in the connection handler directory. 

5 6. The system of claim 1 , wherein the transcoding system includes a 

transcoder directory, the transcoder directory storing transcoder data. 

7. The system of claim 6, wherein the transcoder data comprises 
transcoder data associated with at least one transcoder. 

10 

8. The system of claim 6, wherein the transcoder data comprises a 
network address specifying the location of a transcoder. 

9. The system of claim 8, wherein the transcoder system is operable to 
15 access the location specified by the network address, retrieve the transcoder, and 

store transcoder data associated with the transcoder in the transcoder directory. 

1 0. The system of claim 1 , wherein the connection data includes accept 
data indicating an acceptable content type that the mobile communication device is 

20 operable to receive. 

1 1 . The system of claim 1 0, wherein the connection handler is operable to 
determine a received content type of the information content received from the 
information source and determine whether the received content type matches the 
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acceptable content type. 

12. The system of claim 1 1 , wherein the connection handler is further 
operable to select one or more transcoders to transcode the information content 

5 where the received content type does not match the acceptable content type. 

13. The system of claim \ 1 , wherein the connection handler is further 
operable send an error message to the mobile communication device if the 
information content cannot be transcoded into the acceptable content type. 

10 

14. The system of claim 6, wherein the transcoding system is operable 
generate and store mapping data comprising transcoding chains, each transcoding 
chain selecting one or more transcoders to transcode the information content from a 
respective input content type into a respective output content type. 

15 

15. The system of claim 14, wherein the mapping data is updated upon the 
addition or deletion of transcoding data. 

16. The system of claim 14, wherein the connection handler is operable to 
20 determine a received content type of the information content received from the 

information source, to determine an acceptable content type that the mobile 
communication device is operable to receive, and to select one of the transcoding 
chains to transcode the information content from the received content type into the 
acceptable ^content type. 



58 



WO 03/007617 PCT/CA02/01072 

17. The system of claim 1 , wherein the connection handler is operable to 
specify a list of content types in order of preference and to provide the list of content 
types to the information source. 

18. The system of claim 17, wherein the connection handler is operable to 
determine a received content type of the information content received from the 
information source, to determine an acceptable content type that the mobile 
communication device is operable to receive, and to select the one or more 
transcoders to transcode the information content from the received content type into 
the acceptable content type. 

19. The system of claim 1, wherein the connection handler is operable to 
determine a type of the mobile communication device, and to select the one or more 

15 transcoders from the plurality of transcoders based on the determination. 

20. The system of claim 1 , wherein the connection handler is operable to 
determine an address associated with the mobile communication device, and to 
select the one or more transcoders from the plurality of transcoders based on the 

20 determination. 

21 . The system of claim 1 , wherein the connection handler is operable to 
determine an address associated with the information source, and to select the one 
or more transcoders from the plurality of transcoders based on the determination. 
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22. The system of claim 17, wherein: 

the information content includes multiple different content types; and 
the connection handler is operable to select a respective transcoder to 
5 transcode the information content of each of the multiple different content types. 

23. A method for providing remote data access to a mobile communication 
device, comprising the steps of: 

receiving a connection request; 
10 establishing a connection with an information source responsive to the 

connection request; 

receiving information content from the information source; 

providing a plurality of transcoders, each transcoder being configured to 
transcode information content from a respective input content type into a respective 
. 15 output content type; 

transcoding the information content using one or more of the plurality of 
transcoders to create transcoded information content; and 

forwarding the transcoded information content to the mobile communication 
device. 

20 

24. The method of claim 23, wherein the step of receiving a connection 
request comprises the step of receiving a connection request from the mobile 
communication device. 
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25. The method of claim 23, wherein the connection request identifies the 
information source. 



26. The method of claim 25, wherein the step of establishing a connection 
with an information source responsive to the connection request comprises the step 
of sending an information request to the information source. 

27. The method of claim 26, wherein: 

the connection request conforms to a first communication protocol; and 
the information request conforms to a second communication protocol. 

28. The method of claim 27, wherein the second communication protocol 
is Hypertext Transfer Protocol (HTTP). 

29. The method of claim 26, wherein the connection request identifies one 
or more accepted content types, further comprising the steps of: 

determining whether any of the plurality of transcoders are configured to 
transcode any further content types into any of the one or more accepted content 
types; and 

including the one or more accepted content types and the further content 
types in the information request. 

30. The method of claim 23, wherein: 

the connection request identifies one or more accepted content types; and 
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the step transcoding the information content using one or more of the plurality 
of transcoders to create transcoded information content comprises the step of 
determining if a received content type of the information content may be transcoded 
into one or more of the accepted content types. 

5 

31 . The method of claim 30, wherein the step of determining if a received 
content type of the information content may be transcoded into one or more of the 
accepted content types comprises the steps of: 

determining whether any of the plurality of transcoders are configured to 
10 transcode the received content type into the one or more of the accepted content 
types; and 

selecting a transcoder for transcoding the information content into one of the 
accepted content types where any of the plurality of transcoders are configured to 
transcode the received content type into the one or more of the accepted content 
15 types. 

32. The method of claim 31 , further comprising the step of discarding the 
information content where none of the plurality of transcoders are configured to 
transcode the received content type into the one or more of the accepted content 

20 types. 

33. The method of claim 31 , further comprising the step of performing a 
default transcoding operation on the information content where none of the plurality 
of transcoders are configured to transcode the received content type into the one or 
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more of the accepted content types. 

34. The method of claim 33, wherein the step of performing a default 
transcoding operation on the information content comprises the step of passing the 
information content. 

35. The method of claim 33, wherein the step of performing a default 
transcoding operation on the information content comprises the step of transcoding 
the information content into a content type forwarded to the mobile communication 
device in response to a previous connection request. 

36. The method of claim 30,. wherein: 
the information content comprises multiple content types; and 
the step of determining if a received content type of the information content 

be transcoded into one or more of the accepted content types comprises the 
of: 

determining whether any of the plurality of transcoders are configured 
to transcode any of the multiple content types into the one or more of the 
accepted content types; and 

selecting a respective transcoder for transcoding the information 
content of each of the multiple content types into one of the accepted content 
types where any of the plurality of transcoders are configured to transcode 
any of the multiple content types into the one or more of the accepted content 
types. 
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37. The method of claim 23, wherein: * 

the information content comprises multiple content types; and 
the step transcoding the information content using one or more of the plurality 
5 of transcoders to create transcpded information content comprises the step of 

selecting a respective transcoder for transcoding the information content of each of 

the multiple content types. 

38. The method of claim 23, wherein the step transcoding the information 
10 content using one or more of the plurality of transcoders to create transcoded 

information content comprises the steps of: 

determining a type of the mobile communication device; and 

selecting one or more of the plurality of transcoders associated with the type 

of the mobile communication device. 

15 

39. The method of claim 38, wherein the step of selecting one or more of 
the plurality of transcoders associated with the type of the mobile device comprises 
the step of accessing a mapping table which maps mobile communication device 
types to transcoders. 

20 

40. The method of claim 23, wherein the step transcoding the information 
content using one or more of the plurality of transcoders to create transcoded 
information content comprises the steps of: 

determining an identifier associated with the mobile communication device; 
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and 

selecting one or more of the plurality of transcoders associated with the 
identifier of the mobile communication device. 

41 . The method of claim 23, further comprising the step of mapping the 
plurality of transcoders to create a plurality of transcoding chains, each transcoding 
chain associating one or more transcoders to transcode a respective input content 
type into a respective output content type. 

42. The method of claim 41 , wherein the connection request identifies one 
or mpre accepted content types, and wherein the step of transcoding the information 
content using one or more of the plurality of transcoders to create transcoded 
information content comprises the steps of: 

determining a received content type of the information content; 

searching the transcoding chains for a respective input content matching the 
received content type and a respective output content type matching one of the one 
or more accepted content types; and 

selecting a transcoding chain to transcode the information content. 

43. The method of claim 23, wherein the step of transcoding the 
information content using one or more of the plurality of transcoders comprises the 
steps of: 

transcoding the information content into an intermediate content type; and 
transcoding the content from the intermediate format into a final content type. 
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44. The method of claim 23, wherein the connection request identifies one 
or more accepted content types, and wherein the step of establishing a connection 
with the information source comprises the steps of: 

searching the plurality of transcoders for a set of transcoders configured to 
transcode information content into the one or more accepted content types; 

generating a list of respective input content types corresponding to the set of 
transcoders; and 

sending the list of respective input content types and the one or more 
accepted content types to the information source. 

45. The method of claim 23, wherein the step of transcoding the 
information content using one or more of the plurality of transcoders comprises the 
steps of: 

sending the information content to a transcoding system; and 

receiving the transcoded information content from the transcoding system. 

46. The method of claim 23, wherein the step of forwarding the transcoded 
information content to the mobile communication device comprises the step of 
encrypting the transcoded information content. 

47. The method of claim 23, wherein the step of forwarding the transcoded 
content to the mobile communication device comprises the step of compressing the 
transcoded content. 
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48. The method of claim 23, wherein the step of forwarding the transcoded 
content to the mobile communication device comprises the step of encrypting the. 
transcoded content. 

49. The method of claim 23, wherein the information source is a private 
information source configured to operate within a private computer network behind a 
security firewall. 

50. The method of claim 23, further comprising the steps of: 
generating a list of transcoders according to an order of preference; and 
selecting one of the transcoders in the list of transcoders based on the order 

of preference. 

51 . The method of claim 23, wherein the input content types and output 
content types include content types selected from the group consisting of Wireless 
Markup Language (WML), Hypertext Markup Language (HTML), compiled WML 
(WMLC) and Extensible Markup Language (XML). 

52. A system for providing remote cjata access to a mobile communication 
device, comprising: 

means for receiving a connection request identifying one or more accepted 
content types; 

means for establishing a connection with an information source responsive to 
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the connection request; 

means for receiving information content from the information source; 
means for providing a plurality of transcoders and for transcoding the 
information content into a transcoded information content using one or more of the 
plurality of transcoders, each transcoder being configured for transcoding 
information content from a respective input content type into a respective output 
content type; and 

means for forwarding the transcoded information content to the mobile 
communication device. 

53. The system of claim 52, wherein the means for receiving a connection 
request identifying one or more accepted content types receives the connection 
request from the mobile communication device. 

15 54. The system of claim 53, wherein the connection request from the 

mobile communication device identifies the information source using an Internet 
protocol (IP) address. 

55. The system of claim 54, wherein the means for receiving information 
20 content from the information source determines if a received content type of the 

information content is one of the accepted content types. 

56. The system of claim 52, wherein the means for receiving information 
content from the information source determines if any of the plurality of transcoders 
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are configured to transcode the information content into the one or more of the 
accepted content types and selects one of the plurality of transcoders to transcode 
the information content into one of the accepted content types where any of the 
plurality of transcoders are configured to transcode the information content into the 
5 one or more of the accepted content types. 

57. The system of claim 56, wherein the one or more accepted content 
types are classified by an order of preference and the selection of the one of the 
transcoders is based upon the order of preference of the one or more accepted 

10 content types. 

58. The system of claim 56, wherein the means for receiving information 
content from the information source selects a default transcoder where none of the 
plurality of transcoders are configured to transcode the information content into the 

1 5 one or more of the accepted content types. 

59. The system of claim 58, wherein the default transcoder discards the 
information content 

20 60. The system of claim 58, wherein the means for forwarding returns an 

error indication to the mobile communication device where none of the plurality of 
transcoders are configured to transcode the information content into the one or more 
of the accepted content types. 
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61 . The system of claim 60, wherein the means for establishing a 
connection returns an error indication to the information source where none of the 
plurality of transcoders are configured to transcode the information content into the 
one or more of the accepted content types. 

5 

62. The system of claim 58, wherein the default transcoder is operable to 
pass the information content. 

63. The system of claim 58, wherein the default transcoder is operable to 
10. transcode the information content into a content type forwarded to the mobile 

communication device in response to a previous connection request from the mobile 
communication device. 

64. The system of claim 63, further comprising a transcoder configuration 
15 file including file entries associated with each of the plurality of transcoders; and 

wherein the means for receiving information content from the information source 
determines whether any of the transcoders are configured to transcode the 
information content into one or more of the accepted content types by searching the 
configuration file. 

20 

65. A system for accessing data over a network, comprising: 

a mobile communication device operable to transmit a connection request 
over the network and operable to receive information content of a first content type, 
the connection request comprising a network address specifying the location of a 
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first transcoder operable to transcode information content into the first content type. 



66. . The system of claim 65, wherein the connection request further 
comprises a list of alternate transcoders, each alternate transcoder operable to 
transcode the information content into a respective alternate content type. 

67. The system of claim 65, wherein the connection request further 
comprises a list of acceptable content types in order of preference, the first content 
type first in the order of preference, and wherein the first transcoder is operable to 
transcode the information content into the first content type. 

68. The system of claim 67, wherein the connection request further 
comprises user priorities including high data priority and high time priority. 

69. The system of claim 67, wherein the mobile communication device is 
further operable to encrypt the connection request prior to transmitting the 
connection request. 

70. A method of providing data over a network comprising the steps of: 
providing a plurality of transcoders, each transcoder operable to transcode an 

input content type into an output content type; 

mapping the plurality of transcoders to create a plurality of map entries, each 
map entry associating one or more transcoders to transcode a respective received 
content type into a respective accepted content type; 
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receiving a request for the information content; 
receiving the information content; 

determining a received content type of the information content; 
determining an accepted content type; 
5 determining whether the received content type matches the accepted content 

type, and selecting a map entry to transcode the information content from the 
received content type into the accepted content type where the received content 
type does not match the accepted content type; and 

transmitting the information content in the accepted content type in response 
10 to the request for the! information content. 

71 . The method of claim 70, wherein the step of mapping a plurality of 
transcoders to create a plurality of map entries, each map entry associating one or 
more transcoders to transcode a respective received content type into a respective 

15 accepted content type, comprises the steps of: 

determining the input content types for the plurality of transcoders; 
determining the output content types for the plurality of transcoders; 
creating a plurality of map entries, each map entry associating a respective 
received content type with a respective accepted content type; and 
20 for each map entry, selecting one or more transcoders to transcode the 

respective received content type into the respective accepted content type. 

72. The method of claim 71 , wherein the step of determining the accepted 
content type comprises the step of receiving an accepted content type identifier. 
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73. The method of claim 70, wherein the step of receiving the information 
content comprise the steps of: 

establishing a connection with an information source; 
receiving the information content from the information source; and 
determining the received content type of the information content received 
from the information source. 

74. The method of claim 70, further comprising the steps of: 
comparing the accepted content type to the respective accepted content 

types of each map entry; 

generating a list of respective received content types corresponding to the 
respective accepted content types that match the accepted content type; and 

transmitting the list of respective received content types and the accepted 
content type to an information source. 
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